1. Field of the Invention
The present invention relates to methods and apparatus for use in a so-called push to talk over cellular service.
2. Description of Related Art
Walkie-talkie type services have long proved popular amongst users who wish to communicate brief messages quickly between one another. Conventionally, such services have been provided by two-way portable radios which utilize a dedicated part of the radio spectrum, but which only allow users to communicate with a small group of pre-selected users who utilize similar terminals and who are within range of the relatively short operating range of the radios. More recently, services have been introduced into the United States which piggy-back on the existing cellular telephone infrastructure. However, these services have been proprietary in nature and have not allowed users to communicate between different operator networks.
In an attempt to broaden the use of walkie-talkie type services, an industry grouping known as the Open Mobile Alliance (www.openmobilealliance.org) has been established with the aim of standardizing suitable protocols which will allow inter-network operability for Walkie-Talkie services offered over cellular networks. The service established by the various standards is known as Push to talk Over cellular (PoC). PoC proposes that associated speech data will be transported over a packet switched access network. In the case of GSM and UMTS, this will be the general packet radio service (GPRS) or 3G access network. In other network architectures, analogous packet switched access networks will be utilized for transporting talk data. Push to Talk services may also be offered over circuit switched access networks, although this is not the preferred option.
The Push to talk over Cellular (PoC) system is typically implemented on GSM/GPRS/3G networks and which makes use of the IP Multimedia Subsystem (IMS) standardized by the 3rd Generation Partnership Project to facilitate the introduction of advanced data services into cellular networks, and in particular of real-time multimedia services. The IMS relies upon the Session Initiation Protocol (SIP) which has been defined by the Internet Engineering Task Force (IETF) for the setting up and control of multimedia IP-based sessions. A PoC Server is located within the IMS or is attached thereto, and implements the functionality for setting up and controlling PoC Sessions.
Existing push-to-talk (PTT) systems typically use a control mechanism to grant one of the users the right to speak while other users in the communication are denied such right and are in listening mode. Such control mechanism is typically referred to as floor control, talker arbitration, talk burst control, etc. For example, the Open Mobile Alliance is currently working on a specification of Push-To-Talk over Cellular (PoC) system, which includes Talk Burst Control Protocol (TBCP).
To request the right to speak on behalf of the user, the terminal (PoC Client) typically sends a request message to the controller (PoC Server). The controller typically responds either granting or rejecting the request. The controller typically restricts the time the user is allowed to talk, typically by starting an allowed talk timer when it grants the request, and uses some mechanism to interrupt the user, typically by sending a revoke message to the user's terminal or by simply not forwarding the user's media. The user who is interrupted by the controller is typically penalized by the controller in some way, e.g. by not granting the user the right to speak for a certain period of time.
The next version of OMA PoC (herein called “PoC 2”, with the previous version being called “PoC 1”) is evolving in OMA. Part of the new functionality in PoC 2 is to include new media types, allowing the sending of pictures, video etc in the PoC Sessions. However, an end user or client may only be able to (or opt to) handle a subset of all the available media. In view of this there will be requirements to include functionality for media barring. The following extract is from the OMA PoC 2 Requirement Document [OMA-RD-PoC-V2—0-20050902-D Push to Talk Over Cellular 2 Requirements, Draft Version 2.0-02. September 2005]: “In addition to what is specified in PoC 1.0 the incoming PoC Media Barring feature is needed when the receiving PoC User does not want to receive certain media at certain moment. He can require the barring without interfering to the conversion and media sharing within the rest group”. Also from the OMA PoC 2 Requirement Document: “The PoC Client MAY support separate incoming media barring for each media type”; “The PoC Client MAY support different accept and reject rules for each media type”; “The PoC Service Infrastructure SHALL support separate in-coming PoC Media barring for each media type”; “The PoC Service Infrastructure SHALL use the manual answer mode as the default answer mode for the PoC Sessions when video is the media (The PoC User can configure the answer mode as he wishes)”; “The PoC Service Infrastructure SHALL use the automatic answer mode as the default answer mode for the PoC Sessions with only messaging media or when adding messaging to the on-going PoC Session”; “The PoC Service Infrastructure SHALL use the answer mode according to the Answer Mode Setting the same way as PoC1 specified”; and “The PoC Service Infrastructure SHALL use different accept and reject rules for each media type, if configured by the PoC Client”.
PoC 1 does not contain functionality for Media Barring; this is new proposed functionality in PoC 2. PoC 2 will enrich the communication with the new media types, such as video, text messaging etc, in a PoC session compared to PoC 1 where only audio/talkburst is possible. A PoC 2 session can use, for example, audio/talkbursts in parallel with video. From an end user's perspective there may be situations where he/she wishes to limit the different medias that are used in a PoC Session. For example the user may only want to accept audio/talkburst media and not video media. Reasons for this may include being in an environment or circumstance where video, is not appropriate to use, or perhaps in a region of limited bandwidth, or having a low battery level and knowing that video display may be too much of a power drain. It is the recipient (that is the terminating user of the PoC call) that chooses to bar the media offered in the session of the originating user, rather than the sender who chooses not to send certain types of media.
PoC (and IMS in general) is divided up into a control plane, where SIP signaling is used, and a media plane, where the payload (voice, video etc) is transported using various protocols such as RTP, MSRP etc. When setting up a PoC Session (or any other SIP session), information about what media will be used for that session is transported in the Session Description Protocol for multimedia sessions, SDP [RFC 2327], which is part of the SIP message. This is used to align the media streams from the sender and the recipient. The sender sends information about each media type it wants to use in the session, and the recipient will answer with all or a subset of the offered media.
Basic operation is to determine what capabilities the originating and terminating clients are jointly capable of. For example, the originating client may have a camera with a good color screen, enabling video calls, but the recipient terminal may be a low-end terminal without a screen—in which case there is no need to start a video session. However, the same functionality can be lifted to the end user where he/she can determine what kind of communication it wants to establish with the other user.
The normal case is that the recipient's client will answer, for each incoming session, which of the offered media in the SDP it can or will accept for the session. There are several limitations to this:
Firstly, in a mobile environment, if none of the media that is offered by the originator can be accepted by the recipient, there has been a wasted roundtrip over the air interface.
Secondly, in the future the concept of media barring may be expanded to make it possible to provide different media barring depending of who is calling (for example “I do not allow video media for my work colleagues but I do for my family”), then each client needs to keep track of all access rules. This is something that is normally handled by the network.
Thirdly, in PoC there is a feature for Automatic Answer, where the PoC session is automatically answered and the user does not explicitly answer in order to speed up session set up and usability. For PoC 2 video media it is proposed never to use Automatic Answer for privacy reasons. That implies that every session containing video will require a manual answer from the user even if it does not want to handle video. An example is where a recipient has set AutoAnswer=TRUE and VideoMedia=FALSE; if the recipient with these settings gets an invite to a PoC session containing both Audio and Video, the AutoAnswer feature cannot be used since media Video in a session implies that AutoAnswer is overridden.
It is desirable to address one or more of the above issues.
One option for media barring would be to set a parameter in the PoC Server for each PoC Client which sets out what media that Client has opted to handle, and then the PoC server would bar unwanted media on the media plane. With such a solution, the control plane for PoC will still contain unnecessary media parameters (SDP) for media that the user does not want to handle. Also, this would lead to difficulties when implementing the PoC Client as that would need to be a means for correlating what media barring has already been set in the PoC Server with the signaling used for the control plane. When using multiple clients, all this would need to be coordinated between the clients.